“Multicasting” refers to the delivery of information to a group of nodes in a telecommunications network simultaneously using the most efficient strategy to deliver the messages over each physical link of the network only once. One application for multicasting is decentralized conferencing, in which a plurality of nodes, such as telecommunications endpoints, exchange audio or video information with one another and not through a centralized server.
Internet Protocol multicast, or “IP multicast,” was the earliest approach to decentralized conferencing. In IP multicast, the multicast function is implemented at the network layer of an interconnection reference model. IP multicast relies on hardware such as routers to provide the multicast support; consequently, the inconsistent deployment of multicast-enabled routers has caused many multicast communication applications to fail.
Developers have since turned to “multiple unicast” to implement one-to-many communication. Multiple unicast, however, has its own problems. In contrast to IP multicast, which ensures only one packet on any physical link, multiple unicast replicates data at the source, making the link between the source node and the closest network node a severe bottleneck. Multiple unicast is also unable to limit throughput to accommodate the least capable member in a multiparty conference, which can be a problem as connectivity on the Internet is heterogeneous, ranging from high speed T1 lines, cable modems, and ADSL, to slow-speed dial-up connections.
Not surprisingly, there has been a surge of “application-layer multicast” (ALM) systems designed for various types of applications. Compared with other approaches, such as IP multicast or multiple unicast, ALM-based solutions can better handle network transmission latency and do not require multicast support in the underlying network. However, the ALM-based approaches in the prior art typically assume that all of the nodes participating in a conference call support audio mixing, which is not always true. For example, a cell phone connected through a Public-Switched Telephone Network (PSTN) gateway to a Voice over Internet Protocol (VoIP) network might not support audio mixing. The prior-art ALM-based approaches often cannot even handle a relatively simple three-way call with one node supporting the mix-and-distribute function known as “conference bridging” (or just “bridging”) on behalf of the two other nodes involved. In addition, the prior-art ALM-based approaches are often not scaleable in terms of bandwidth utilization. This is because there is no mixing performed along the routing path, so every node's audio stream must reach all of the other nodes involved in a conference call.
Mixing the audio streams by using a centralized conferencing server can reduce the required bandwidth. However, a centralized conference is not always appropriate for an environment with limited bandwidth. For example, FIG. 1 in the prior art depicts conferencing configuration 100 with centralized server 101 that serves branches 110-1 and 110-2, each of the two branches having sufficient intranet bandwidth but limited inter-branch bandwidth. Using a layered conferencing approach (as depicted) increases the bandwidth and processing within a branch but reduces the inter-branch bandwidth usage, and as a result might be suitable for some scenarios. However, it requires the deployment of nodes that can handle audio mixing in each branch, namely mixer node 102-1 providing the mixing for nodes 103-1 and 103-2 and mixer node 102-2 providing the mixing for nodes 103-3, 103-4, and 103-5.
In view of these prior-art techniques, what is needed is a conferencing system that considers both the bandwidth-handling and the mixing capabilities of the participating peer nodes when setting up a decentralized peer-to-peer conference, without some of the disadvantages in the prior art.